cold email: fail toward not blocking, and stop clobbering learned patterns - #3075

Guiding rule

When a check that feeds the cold email decision cannot answer, default to leaving the sender alone.

The two errors are not symmetric. A wrongly blocked sender is labelled, archived out of the inbox, and on accounts with NOTIFY_SENDER enabled, auto-emailed to say their message was unsolicited outreach. A missed cold email costs the user one email in the inbox.

Fail toward not blocking

Outlook prior-contact lookup returned false on error. hasPreviousCommunicationsWithSenderOrDomain wrapped its Graph queries in a catch that returned false. But false means "no prior contact", which is exactly the input that pushes the blocker toward blocking. A transient Graph outage could therefore start blocking established contacts. It now fails toward reporting contact.

The four inner per-query .catch()es had the same shape, resolving a failed query to { value: [] } so a partial failure looked like a confirmed absence of history. They now propagate to the outer handler.

Gmail's implementation has no catch, so errors already propagate and no blocking occurs. Left as is.

A message without a date or id can no longer be classified as cold. That combination makes the prior-contact check unrunnable, and the old fallback treated "couldn't check" as "no prior contact".

Pattern writes no longer clobber

saveLearnedPattern wrote exclude and source on every upsert, including for callers that never passed them. exclude defaulted to false, so any caller omitting it would silently un-exclude a sender the user had explicitly corrected, and re-blocking begins.

Callers now overwrite only what they supply, and source keeps recording how the pattern was first learned rather than what touched it last. Two consumers depend on that: undoing a junk action, and the audit trail.

Reachable today via analyze-sender-pattern, though it has written zero cold-email patterns in production so far, so this is a latent footgun rather than a live regression. Prisma already skips undefined on update, so reason/threadId/messageId were never actually being nulled.

Skips are not failures

NOTIFY_SENDER is in ACTION_RESULT_FAILURE_TYPES, so the internal-sender guard returning { success: false } was persisted as ExecutedActionStatus.FAILED with an executionError, and pushed into actionFailures, which flips the whole rule to ERROR. A deliberate policy decision was being reported as an execution failure.

Actions can now return { skipped: true }, handled in both executors, following the ExecutedActionStatus.SKIPPED precedent already used for the automated-archive exception.

One thread read per junk

Gmail labels every message in a thread as spam, so junking an N-message thread fires N webhook events. Spam learning is thread-scoped, so all N produced the same answer, and on the conversation path nothing was written, meaning the duplicate guard never engaged and every event paid a full threads.get that downloads all N bodies.

A batch-scoped set of thread ids means only the first event does the work. Junking a 25-message thread goes from 25 thread reads to 1.

Tests

Each change was mutation-tested: reverting the fix makes its test fail.

Full suite: 495 files passed, 97 skipped, 0 failed. Lint clean, no new type errors.

🤖 Generated with Claude Code